Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-019.txt

Text File | 1992-11-18 | 53.1 KB | 1,548 lines | [TEXT/MPS ]

C.S.M.P. Digest             Mon, 16 Mar 92       Volume 1 : Issue 19

Today's Topics:

    sfdefault MPW tool
    Think C 5.0 Changes for Vol II Mac C Primer
    Help: Corrupted Resource File
    Building NCSA Telnet (2.4)
     GWorld and 32 bit QuickDraw question
    Finding out who I am on AppleTalk
    MacApp vs. TCL (think pascal) pros and cons?
    Accessing PC files from a Mac
    HELP!! mistakenly trashed folder


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu (try skinner.cs.uoregon.edu if that doesn't work).  This is also the home
of the comp.sys.mac.programmer Frequently Asked Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Tim Endres)
Subject: sfdefault MPW tool
Date: 13 Feb 92 03:53:44 GMT
Organization: ICE Engineering, Inc.


Here is a stupid MPW tool trick. Feed this tool a path name and your
next open via SFGetFile() will be pointed to that directory. Very
nice for setting up context driven opens like "Open C Header..."
or "Open Resource Header...".

usage: sfdefault pathname

tim.
- ---------------


#include <types.h>
#include <standardfile.h>
#include <stdio.h>
#include <string.h>

#define FALSE            (Boolean)0

#define SFSaveDisk        (* (short *) 0x0214)
#define CurDirStore        (* (long *)  0x0398)

main(int argc, char *argv[])
    {
    int                myerr;
    long            dirID;
    short            vRefNum;
    char            pascal_name[256], *ptr;
    WDPBRec            wpb;
    CInfoPBRec        cpb;
    HParamBlockRec    pb;

    if (argc > 1)
        {
        pascal_name[0] = '\0';
        wpb.ioCompletion = 0;
        wpb.ioNamePtr = pascal_name;

        myerr = PBHGetVol(&wpb, FALSE);

        if (myerr != noErr)
            {
            fprintf(stderr, "error #%d from PBHGetVol().\n", myerr);
            exit(2);
            }

        vRefNum = wpb.ioWDVRefNum;
        dirID = wpb.ioWDDirID;

        if (argv[1][0] != ':')
            {
            ptr = strchr(argv[1], ':');
            if (ptr != NULL)
                {
                /* Full path name, get it's vRefNum... */
                strncpy(&pascal_name[1], argv[1], (int)(ptr - argv[1])+1);
                pascal_name[0] = (ptr - argv[1])+1;

                pb.volumeParam.ioCompletion = 0;
                pb.volumeParam.ioNamePtr = pascal_name;
                pb.volumeParam.ioVRefNum = 0;
                pb.volumeParam.ioVolIndex = -1;

                myerr = PBHGetVInfo(&pb, FALSE);

                if (myerr != noErr)
                    {
                    fprintf(stderr, "error #%d from PBHGetVInfo().\n", myerr);
                    exit(2);
                    }

                vRefNum = pb.volumeParam.ioVRefNum;
                }
            }

        strcpy(pascal_name, argv[1]);
        c2pstr(pascal_name);

        cpb.hFileInfo.ioCompletion = 0;                /* Synchronous */
        cpb.hFileInfo.ioNamePtr = pascal_name;
        cpb.hFileInfo.ioVRefNum = vRefNum;            /* Returned here */
        cpb.hFileInfo.ioFDirIndex = 0;                /* Use ioDirID *and* ioNamePtr */
        cpb.hFileInfo.ioDirID = 0;                    /* same offset as ioFlNum */

        myerr = PBGetCatInfo(&cpb, (Boolean)0);        /* Synchronous */

        if (myerr != noErr)
            {
            fprintf(stderr, "error #%d from PBGetCatInfo().\n", myerr);
            exit(2);
            }

        if ((cpb.hFileInfo.ioFlAttrib & ioDirMask) != 0)
            {
            dirID = cpb.dirInfo.ioDrDirID;
            }
        else
            {
            dirID = cpb.hFileInfo.ioFlParID;
            }

        SFSetDefault(dirID, vRefNum);
        }

    }


SFSetDefault(dirid, vrefnum)
long    dirid;
short    vrefnum;
{

    SFSaveDisk = vrefnum * -1;
    CurDirStore = dirid;
    }


#ifdef NEVER_DEFINED

C -mbg full {active}
Link -t MPST -c 'MPS '        6
    -o sfdefault            6
    {active}.o                6
    {Libraries}Interface.o    6
    {Libraries}RunTime.o    6
    {CLibraries}StdCLib.o
sfdefault Fire:
sfdefault Sea:doc:
sfdefault "Earth:System Folder:Control Panels:"

mv sfdefault {tools}

#endif



---------------------------

From: [e-mail] (Jim Cook)
Subject: Think C 5.0 Changes for Vol II Mac C Primer
Date: 28 Jan 92 23:13:45 GMT
Organization: Prime Computer, Inc.

Because someone asked, I'm also published the changes for Vol II of the
Macintosh Programming Primer.  The primer was published based on Think 4.0.
The following will allow you to run the programs under Think 5.0.
Send any questions to the book's author - I'm just the messanger!

Jim
<[e-mail]>

- -------------------------------------------------------------------------

Dear Mac C Primer (Volume II) reader,

With the introduction of a new version of THINK C (v5.0), you'll need to make
some changes in your  source code to maintain compatibility:

cdev.c:
1) (p. 67) Insert line, just after the last #define:
        short    FindFontNumber();

Tester.c:
1) (p. 95) Replace #define MOVE_TO_FRONT from
        -1L
    to
        (WindowPtr)-1L

2) (p. 97) Change BeginUpdate( gTheEvent.message ) to
            BeginUpdate( (WindowPtr)gTheEvent.message )

3) (p. 97) Change EndUpdate( gTheEvent.message ) to
            EndUpdate( (WindowPtr)gTheEvent.message )

DLOG.c:
1) (p. 111) Replace #define MOVE_TO_FRONT from
        -1L
    to
        (WindowPtr)-1L

ColorInfo.c:
1) (p. 136) Replace the line:
        #include "ColorToolbox.h"
    with
        #include "Picker.h"

Palette.c:
1) (p. 153) Replace the line:
        #include "ColorToolbox.h"
    with the two lines:
        #include "Palettes.h"
        #include "Picker.h"

2) (p. 153) Replace #define MOVE_TO_FRONT from
        -1L
    to
        (WindowPtr)-1L

ColorTutor.c:
1) (p. 171) Replace the line:
        #include "ColorToolbox.h"
    with the two lines:
        #include "Palettes.h"
        #include "Picker.h"

2) (p. 171) Replace #define MOVE_TO_FRONT from
        -1L
    to
        (WindowPtr)-1L

GWorld.c:
1) (p. 203) Replace the two lines:
        #include "ColorToolbox.h"
        #include "QuickDraw32Bit.h"
    with the two lines:
        #include "Picker.h"
        #include "QDOffscreen.h"

2) (p. 203) Replace #define MOVE_TO_FRONT from
        -1L
    to
        (WindowPtr)-1L

FormEdit.c:
1) (p. 244) Replace #define MOVE_TO_FRONT from
        -1L
    to
        (WindowPtr)-1L

2) (p. 251) In the function DoTEKey(), replace the line:
        tempStr[ i+1 ] = (*text)[ i ];
    with the line:
        tempStr[ i+1 ] = (*(char **)text)[ i ];

3) (p. 257) In the function HandleEditChoice(), replace the line:
        tempStr[ i+1 ] = (*text)[ i ];
    with the line:
        tempStr[ i+1 ] = (*(char **)text)[ i ];

4) (p. 266) In the function NewClikLoop(), replace the declaration:
        int            amount;
    with the line:
        short            amount;

Starter. :
1) Make a copy of the "Starter Folder" found in the "TCL 1.1 Demos" folder in
your "Development" folder.  Next, copy the following files from your old
"MyStarter" folder into this new folder:
        - CDragPane.c
        - CDragPane.h
        - CMouse.c
        - CMouse.h
        - CStarterDoc.c
        - CStarterDoc.h
        - CStarterPane.c
        - CStarterPane.h
        - Starter.c
    You should be copying 9 files, replacing their counterparts in the new
    folder.  Do NOT copy the files CStarterApp.c and CStarterApp.h!!!!!
    Start up THINK C by double-clicking the file Starter.  in this new folder.

2) Select Add... from the Source menu and add the files CDragPane.c and
CMouse.c
to the project.  Make sure you add the two files to the first segment in the
project window.  To select the first segment, click on the file name
CStarterApp.c (in the project window) before you select Add...

3) Select Options... from the Edit menu.
    - Select "Language Settings" from the popup menu.
    - Make sure that the "Language Extensions" check box is checked.
    - Select the "THINK C + Objects" radio button.
    - Make sure the "Strict Prototype Enforcement" check box is checked.
    - Select the "Infer Prototypes" radio button.

4) Edit each of the functions in the files CDragPane.c, CMouse.c, and
CStarterPane.c.  Change each function's parameter declarations from the old
style to the new style of parameter declaration.  Make sure you edit every
single function!!!  Old style declarations look like this:
        void CDragPane::DoClick( hitPt, modifierKeys, when )
        Point        hitPt;
        short        modifierKeys;
        long        when;
        {
        }
    New style declarations look like this:
        void CDragPane::DoClick( Point hitPt, short modifierKeys, long when )
        {
        }

5) (p. 348) In the file CDragPane.c, in the function IDragPane, change the
   declaration:
        Rect r;
    to
        LongRect r;

6) (p. 349-350) Also in CDragPane.c, in the function DoClick, change the first
five lines from:
        Rect    r;
        Rect    endLocation;

        r = frame;
        EraseRect( &r );

        FrameToEnclR(&r);
    to these eight lines:
        Rect    r;
        Rect    endLocation;
        LongRect    longR;

        FrameToQDR( &frame, &r );
        EraseRect( &r );

        QDToLongRect(&r,&longR);
        FrameToEnclR(&longR);
        LongToQDRect( &longR, &r );

7) (p. 354) In the file CMouse.h, change the three lines:
        void        BeginTracking( Point *startPt );
        void        KeepTracking( Point *currPt, Point *prevPt, Point *startPt);
        void        EndTracking( Point *currPt, Point *prevPt, Point *startPt);
    to:
        void        BeginTracking( struct LongPt *startPt );
        void        KeepTracking( struct LongPt *currPt, struct LongPt *prevPt,
                                    struct LongPt *startPt );
        void        EndTracking( struct LongPt  *currPt, struct LongPt  *prevPt,
                                    struct LongPt  *startPt );

8) (p. 351) In the file CMouse.c, in the function IMouse(), change the
   declaration:
        Rect r;
    to
        LongRect r;

9) (p. 351) Also in the file CMouse.c, in the function IMouse(), change:
        theBounds = r;
    to
        LongToQDRect( &r, &theBounds );

10) (p. 351) Also in the file CMouse.c, in the function BeginTracking(), change
    the function declaration from:
        void CMouse::BeginTracking( Point *startPt )
    to
        void CMouse::BeginTracking( struct LongPt *startPt )

11) (p. 352-353) Also in the file CMouse.c, replace the function KeepTracking()
    with the following:

void CMouse::KeepTracking( struct LongPt *currPt, struct LongPt *prevPt,
                    struct LongPt *startPt )
{
    LongRect    r, f;
    Rect        shortR;
    long        curTicks;
    LongPt        startPosit, newPosit, cp, pp;
    RgnHandle    clipRgn;

    thePanorama->GetPosition( &startPosit );

    clipRgn = NewRgn();

    if ( thePanorama->AutoScroll( currPt )
            || ! EqualLongPt( currPt, prevPt ) )
    {
        thePanorama->GetPosition( &newPosit );

        GetClip( clipRgn );
        QDToLongRect( &((**clipRgn).rgnBBox), &r );
        OffsetLongRect( &r, startPosit.h - newPosit.h,
                startPosit.v - newPosit.v );

        thePanorama->GetFrame(&f);
        PinInRect(&f, (LongPt *)(&(r.top)));
        PinInRect(&f, (LongPt *)(&(r.bottom)));

        LongToQDRect( &r, &shortR );
        ClipRect( &shortR );

        shortR = theLocation;    /* Erase old gray rect */

        curTicks = TickCount();
        while ( curTicks == TickCount() ) ;
        FrameRect( &shortR );
        QDToLongRect( &shortR, &r );

        cp = *currPt;
        pp = *prevPt;
        QDToLongRect( &theBounds, &f );
        PinInRect(&f, &cp);
        PinInRect(&f, &pp);

        OffsetLongRect(&r, cp.h - pp.h, cp.v - pp.v);

        SetClip( clipRgn );

        curTicks = TickCount();
        while ( curTicks == TickCount() ) ;

        LongToQDRect( &r, &shortR );
        FrameRect( &shortR );    /* Draw new gray rect */
        theLocation = shortR;        /* update theLocation instance var */
    }
    DisposeRgn( clipRgn );
}


12) (p. 353) Also in the file CMouse.c, Replace the declaration of the function
    EndTracking() with:

void CMouse::EndTracking( struct LongPt  *currPt, struct LongPt  *prevPt,
                    struct LongPt  *startPt )


13) Add these three lines to the list of include files in the file
    CStarterDoc.c:

#include "TBUtilities.h"
#include "CWindow.h"
#include <Packages.h>

14) In the file CStarterDoc.c, in the function OpenFile(), replace the line:
        theError = theFile->Open(fsRdWrPerm);
    with the line
        theFile->Open(fsRdWrPerm);

15) In the file CStarterDoc.c, in the function OpenFile(), comment
    out each of the lines:
        gApplication->RequestMemory(FALSE, TRUE);
        theFile->ReadAll(&theData);
    and
        gApplication->RequestMemory(FALSE, FALSE);

16) (p. 343) In the file CStarterDoc.c, in the function BuildWindow(), change
    the line:
        Rect            panFrame;
    to
        LongRect        panFrame;

17) (p. 346) In the file CStarterPane.c, in the function DoDrag(), change the
    declaration:
        Rect        boundsRect;
    to
        LongRect        boundsRect;

18) (p. 346) In the file CStarterPane.c, in the function DoDrag(), add the new
    declaration:
        LongPt        longP;

19) (p. 346) In the file CStarterPane.c, in the function DoDrag(), change the
    line:
        TrackMouse( aMouseTask, p, &boundsRect );
    to
        QDToLongPt( p, &longP );
        TrackMouse( aMouseTask, &longP, &boundsRect );

ShowINIT.c:
1) (p. 397) Delete the line:
        #include <Color.h>




---------------------------

From: [e-mail] (Chuck Weinstock)
Subject: Help: Corrupted Resource File
Date: 26 Jan 92 21:38:23 GMT
Organization: Software Engineering Institute, Pittsburgh, PA

I want to record changes to menu selections in my program permanently
(i.e. if the user checks an entry I want that entry checked the next
time the program is launched).  I *thought* the way to do this would
be to do a ChangedResource on the menu handle, and then a
WriteResource.  When I do this, everything looks fine if I open the
resource file using ResEdit.  But when I try to run my program again
it gets an error at the call to GetMenu that reads the modified
resource.

Any ideas?

--
Chuck Weinstock                [e-mail]
Software Engineering Institute        [phone]
Carnegie Mellon University        [phone] (Fax)
Pittsburgh, PA 15213



- -------------------------

From: [e-mail] (Chuck Weinstock)
Subject:  Help: Corrupted Resource File
Date: 27 Jan 92 14:42:34 GMT
Organization: The Software Engineering Institute


In article <[e-mail]>, I wrote:

|> I want to record changes to menu selections in my program permanently
|> (i.e. if the user checks an entry I want that entry checked the next
|> time the program is launched).  I *thought* the way to do this would
|> be to do a ChangedResource on the menu handle, and then a
|> WriteResource.  When I do this, everything looks fine if I open the
|> resource file using ResEdit.  But when I try to run my program again
|> it gets an error at the call to GetMenu that reads the modified
|> resource.
|>
|> Any ideas?
|>

No one knew why the file was corrupted, but several suggested that I
create my own resource to keep status.  It was also pointed out that
the "correct" way to keep status is to create a preferences file for
that purpose.

Thanks to all who responded.



Chuck Weinstock                [e-mail]
Software Engineering Institute        [phone]
Carnegie Mellon University        [phone] (Fax)
Pittsburgh, PA 15213



- -------------------------

From: [e-mail] (Matthew T. Russotto)
Subject:  Help: Corrupted Resource File
Date: 27 Jan 92 15:39:03 GMT
Organization: University of Maryland, College Park, College of Engineering

In article <[e-mail]> [e-mail] (Chuck Weinstock) writes:
>I want to record changes to menu selections in my program permanently
>(i.e. if the user checks an entry I want that entry checked the next
>time the program is launched).  I *thought* the way to do this would
>be to do a ChangedResource on the menu handle, and then a
>WriteResource.  When I do this, everything looks fine if I open the
>resource file using ResEdit.  But when I try to run my program again
>it gets an error at the call to GetMenu that reads the modified
>resource.

Certain info in the MENU resource is changed when you call GetMenu-- if you
do what you described, you trash the MDEF ID.



--
Matthew T. Russotto    [e-mail]    [e-mail]
Your superior intellect is no match for our puny weapons! -- The Simpsons
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)



- -------------------------

From: [e-mail] (Larry Rosenstein)
Subject:  Help: Corrupted Resource File
Date: 29 Jan 92 02:39:12 GMT
Organization: Object Based Systems, Apple Computer, Inc.

In article <[e-mail]> [e-mail] (Chuck Weinstock) writes:
>
>In article <[e-mail]>, I wrote:
>
>|> I want to record changes to menu selections in my program permanently
>|> (i.e. if the user checks an entry I want that entry checked the next
>|> time the program is launched).  I *thought* the way to do this would
>|> be to do a ChangedResource on the menu handle, and then a
>|> WriteResource.  When I do this, everything looks fine if I open the
>
>No one knew why the file was corrupted, but several suggested that I

(I replied by E-Mail, but since no one else seemed to know why, I'm posting
as well.)

The reason is that the original MENU resource contains the defproc ID, but
this gets replaced with the defproc *handle* when GetMenu is called.  If you
just do a ChangedResource you will be writing out the defproc handle,
instead of the ID.

Before writing out the changed MENU you need to restore the ID.  (And then
restore the handle if the menu is still going to be used.)

>create my own resource to keep status.  It was also pointed out that
>the "correct" way to keep status is to create a preferences file for

You should use a separate preferences file instead of modifying the original
application.  But you could still keep the status in a MENU resource.

--
Larry Rosenstein, Apple Computer, Inc.

[e-mail]
(or AppleLink: Rosenstein1)



- -------------------------

From: [e-mail] (Larry Rosenstein)
Subject:  Help: Corrupted Resource File
Date: 29 Jan 92 02:39:12 GMT
Organization: Object Based Systems, Apple Computer, Inc.

In article <[e-mail]> [e-mail] (Chuck Weinstock) writes:
>
>In article <[e-mail]>, I wrote:
>
>|> I want to record changes to menu selections in my program permanently
>|> (i.e. if the user checks an entry I want that entry checked the next
>|> time the program is launched).  I *thought* the way to do this would
>|> be to do a ChangedResource on the menu handle, and then a
>|> WriteResource.  When I do this, everything looks fine if I open the
>
>No one knew why the file was corrupted, but several suggested that I

(I replied by E-Mail, but since no one else seemed to know why, I'm posting
as well.)

The reason is that the original MENU resource contains the defproc ID, but
this gets replaced with the defproc *handle* when GetMenu is called.  If you
just do a ChangedResource you will be writing out the defproc handle,
instead of the ID.

Before writing out the changed MENU you need to restore the ID.  (And then
restore the handle if the menu is still going to be used.)

>create my own resource to keep status.  It was also pointed out that
>the "correct" way to keep status is to create a preferences file for

You should use a separate preferences file instead of modifying the original
application.  But you could still keep the status in a MENU resource.

--
Larry Rosenstein, Apple Computer, Inc.

[e-mail]
(or AppleLink: Rosenstein1)



---------------------------

From: [e-mail] (Bill Jackson)
Subject: Building NCSA Telnet (2.4)
Date: 28 Jan 92 20:49:29 GMT
Organization: Oregon Health Sciences University

I am attempting to build the NCSA Telnet product so I can add a local
modification(s) to it.  Being a complete neophite to the Mac development
environment, I am trying to ascertain what tools I need to do this.  Is ther
a specific compiler/loader I need?  I do not see any instructions in the source
package I downloaded, maybe they assume people at this level know what they
are doing!  I see MPW mentioned - is that all I need>  If so, a specific
release, or what?

Any help appreciated.

--
- -
William Jackson                     Manager, Network Services, Gaines Hall #113
Oregon Health Sciences University (OHSU), 840 SW Gaines Road, Portland,OR 97201
[phone]          Internet: [e-mail]     AT&T Mail: attmail!ohsu3b2!bj



- -------------------------

From: [e-mail] (Scott W. Haney)
Subject:  Building NCSA Telnet (2.4)
Date: 29 Jan 92 01:47:06 GMT

[e-mail] (Bill Jackson) writes:

>I am attempting to build the NCSA Telnet product so I can add a local
>modification(s) to it.  Being a complete neophite to the Mac development
>environment, I am trying to ascertain what tools I need to do this.  Is ther
>a specific compiler/loader I need?  I do not see any instructions in the source
>package I downloaded, maybe they assume people at this level know what they
>are doing!  I see MPW mentioned - is that all I need>  If so, a specific
>release, or what?

>Any help appreciated.

>--
>---
>William Jackson                     Manager, Network Services, Gaines Hall #113
>Oregon Health Sciences University (OHSU), 840 SW Gaines Road, Portland,OR 97201
>[phone]          Internet: [e-mail]     AT&T Mail: attmail!ohsu3b2!bj


  We have been trying to build this product as well.  It is clearly meant to
be built with MPW and requires MPW C.  It also seems to depend on some include
files that don't come with MPW or the distribution.  They are
'MacTCPCommonTypes.h', 'GetMyIPAddr.h', 'TCPPB.h', 'UDPPB.h', and
'AddressXlation.h'.  Does anyone know where to get these files?
If it's legal, I would appreciate it if someone could email them to
me.  Thanks.

  Scott ([e-mail], 128.115.15.39)
--
- -----------------------------------------------------------------------
Scott W. Haney        || Lawrence Livermore N'Lab || The above views are
[e-mail] || P.O. Box 808;  L-644     || mine and not neces-
[phone]        || Livermore, CA  94550     || sarily LLNL's.



- -------------------------

From: [e-mail] (Hugh Weiss)
Subject:  Building NCSA Telnet (2.4)
Date: 29 Jan 92 13:29:10 GMT
Organization: Virginia Tech Computing Center - Distributed Computing Group

In article <haney.696649626@moonshine> [e-mail] (Scott W. Haney) writes:

>>>  We have been trying to build this product [NCSA Telnet] as well.  It
>>> is clearly meant to be built with MPW and requires MPW C.  It also
>>> seems to depend on some include files that don't come with MPW or the
>>> distribution.  They are 'MacTCPCommonTypes.h', 'GetMyIPAddr.h',
>>> 'TCPPB.h', 'UDPPB.h', and 'AddressXlation.h'.  Does anyone know where
>>> to  get these files?  If it's legal, I would appreciate it if someone
>>> could email them to me.  Thanks.

>>>  Scott ([e-mail], 128.115.15.39)

They are part of the "MacTCP Developer's Kit".  Unfortunately they are
licensed software (from Apple) and are not freely distributable.

-Hugh Weiss
-Virginia Tech Computing Center - Distributed Computing Group
[e-mail]   OR   [e-mail]



- -------------------------

From: [e-mail] (Scott W. Haney)
Subject:  Building NCSA Telnet (2.4)
Date: 29 Jan 92 01:47:06 GMT

[e-mail] (Bill Jackson) writes:

>I am attempting to build the NCSA Telnet product so I can add a local
>modification(s) to it.  Being a complete neophite to the Mac development
>environment, I am trying to ascertain what tools I need to do this.  Is ther
>a specific compiler/loader I need?  I do not see any instructions in the source
>package I downloaded, maybe they assume people at this level know what they
>are doing!  I see MPW mentioned - is that all I need>  If so, a specific
>release, or what?

>Any help appreciated.

>--
>---
>William Jackson                     Manager, Network Services, Gaines Hall #113
>Oregon Health Sciences University (OHSU), 840 SW Gaines Road, Portland,OR 97201
>[phone]          Internet: [e-mail]     AT&T Mail: attmail!ohsu3b2!bj


  We have been trying to build this product as well.  It is clearly meant to
be built with MPW and requires MPW C.  It also seems to depend on some include
files that don't come with MPW or the distribution.  They are
'MacTCPCommonTypes.h', 'GetMyIPAddr.h', 'TCPPB.h', 'UDPPB.h', and
'AddressXlation.h'.  Does anyone know where to get these files?
If it's legal, I would appreciate it if someone could email them to
me.  Thanks.

  Scott ([e-mail], 128.115.15.39)
--
- -----------------------------------------------------------------------
Scott W. Haney        || Lawrence Livermore N'Lab || The above views are
[e-mail] || P.O. Box 808;  L-644     || mine and not neces-
[phone]        || Livermore, CA  94550     || sarily LLNL's.



---------------------------

From: [e-mail] (Bill Hofmann)
Subject:  GWorld and 32 bit QuickDraw question
Date: 28 Jan 92 17:31:52 GMT
Organization: Flashpoint

[e-mail] (Omar Souka) writes:
>Can 32 bit quickdraw run on 68000 based macs?  Specifically, can I use
>GWorld calls and expect my code to run on these machines.

Yes, but only under system 7.  1-bit deep GWorlds are supported, but you
still can't do color quickdraw calls (eg, "PaintCOval").

-Bill Hofmann



- -------------------------

From: [e-mail] (Bill Hofmann)
Subject:  GWorld and 32 bit QuickDraw question
Date: 28 Jan 92 17:31:52 GMT
Organization: Flashpoint

[e-mail] (Omar Souka) writes:
>Can 32 bit quickdraw run on 68000 based macs?  Specifically, can I use
>GWorld calls and expect my code to run on these machines.

Yes, but only under system 7.  1-bit deep GWorlds are supported, but you
still can't do color quickdraw calls (eg, "PaintCOval").

-Bill Hofmann



---------------------------

From: [e-mail] (WILLIAM D. BURNS)
Subject: Finding out who I am on AppleTalk
Date: 29 Jan 92 04:05:00 GMT
Organization: Degrading Chaos, unincorporated

Greetings all,
  I am attempting to write an application for a mac lab I work at and
bascially I need to find out what the user name is that the user logged onto
the AppleShare server with.  I can't seem to find any clear cut info on this
stuff in the IM's vols. 1-5.  Am I missing something here?

Also, I will eventually need to set this username into the Chooser's name
field so that we can know who to charge for printer usage (using AppleShare's
Print server thing).

I'm working primarily in Think C but any code/suggestions would be helpful!

Thanks in advance....
Bill ([e-mail])



- -------------------------

From: [e-mail] (Michael Peirce)
Subject:  Finding out who I am on AppleTalk
Date: 30 Jan 92 23:15:01 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (WILLIAM D. BURNS) writes:
> Greetings all,
>   I am attempting to write an application for a mac lab I work at and
> bascially I need to find out what the user name is that the user logged onto
> the AppleShare server with.  I can't seem to find any clear cut info on this
> stuff in the IM's vols. 1-5.  Am I missing something here?
>
> Also, I will eventually need to set this username into the Chooser's name
> field so that we can know who to charge for printer usage (using AppleShare's
> Print server thing).
>
> I'm working primarily in Think C but any code/suggestions would be helpful!

The "chooser name" is stored in string resource with ID = -16096.  You
can grab it with the following line of code:

    chooserNameHandle = GetString(-16096);

where chooserNameHandle is a handle to the (pascal style) string.

The above was true before System 7, and still is to a certain extent.

With System 7 their are now two name strings: the owner name and the Macintosh
name.  String -16096 is now used to identify the Mac and a new string,
ID = -16413, is use used to identify the user.

Typical usage would be owner name = "Michael Peirce"
                   Macintosh name = "Michael's Mac Plus"

System 7 Filesharing uses the name of the Machine as the name of the
server and uses the owner name as the default login name when you
connect TO a server.

Keep in mind that user doesn't HAVE to log in to an AppleShare server
using their default name.  It's easy for them to type in something
else as they are mounting the volume.

I guess if you really need to set these strings you can simply update
the appropriate string resources in the system file.  I'd think twice
before doing this, since some users may frown on you modifying the
system file behind there back.

--  Michael Peirce         --   [e-mail]
--  Peirce Software        --   Suite 301, 719 Hibiscus Place
--  Macintosh Programming  --   San Jose, California USA 95117
--           & Consulting  --   voice: [phone] fax: [phone]
--                         --   AppleLink: peirce & America Online: AFC Peirce



- -------------------------

From: [e-mail] (Marshall Clow)
Subject:  Re: Finding out who I am on AppleTalk
Date: 31 Jan 92 16:51:56 GMT
Organization: Hewlett Packard Color Imaging Division

>> In article <[e-mail]>, [e-mail] (WILLIAM D. BURNS) writes:
>>   I am attempting to write an application for a mac lab I work at and
>> bascially I need to find out what the user name is that the user logged onto
>> the AppleShare server with.  I can't seem to find any clear cut info on this
>> stuff in the IM's vols. 1-5.  Am I missing something here?

> and Micheal Peirce replies:
> The "chooser name" is stored in string resource with ID = -16096.  You
> can grab it with the following line of code:
>     chooserNameHandle = GetString(-16096);
> where chooserNameHandle is a handle to the (pascal style) string.
> The above was true before System 7, and still is to a certain extent.
> With System 7 their are now two name strings: the owner name and the Macintosh
> name.  String -16096 is now used to identify the Mac and a new string,
> ID = -16413, is use used to identify the user.
> Typical usage would be owner name = "Michael Peirce"
>                    Macintosh name = "Michael's Mac Plus"
> [ good comment about relationship between user name and login id deleted ]

Micheal, this is the kind of post I've come to expect from you.
Concise and accurate, and totally lacking in "Well, I'm not
sure but this seems to work for me..." Thank you. The only addition or
suggestion I have is to be sure that the resource comes from the system
file; i.e:

     short saveResFile;
     StringHandle chooserNameHandle;

     saveResFile = CurResFile ();
     UseResFile ( 0 );   /* 0 means system file */
     chooserNameHandle = GetString(-16096);
     UseResFile ( saveResFile );

P.S.    Nice job on the book!

Marshall Clow
Hewlett Packard
San Diego Printer Division
[e-mail]



- -------------------------

From: [e-mail] (WILLIAM D. BURNS)
Subject: Finding out who I am on AppleTalk
Date: 29 Jan 92 04:05:00 GMT
Organization: Degrading Chaos, unincorporated

Greetings all,
  I am attempting to write an application for a mac lab I work at and
bascially I need to find out what the user name is that the user logged onto
the AppleShare server with.  I can't seem to find any clear cut info on this
stuff in the IM's vols. 1-5.  Am I missing something here?

Also, I will eventually need to set this username into the Chooser's name
field so that we can know who to charge for printer usage (using AppleShare's
Print server thing).

I'm working primarily in Think C but any code/suggestions would be helpful!

Thanks in advance....
Bill ([e-mail])



---------------------------

From: [e-mail] (Arnold Spence)
Subject: MacApp vs. TCL (think pascal) pros and cons?
Date: 4 Feb 92 17:40:48 GMT
Organization: Acadia University

Can anyone BRIEFLY make some points about the advantages or disadvantages of
using Think Pascal's TCL 1.1 instead of MacApp 2.0. Is one easier to use than
the other or does one have certain advantages where portability may be a concern
if end_of_message then
  writeln('Arnold B. Spence : [e-mail]');



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  MacApp vs. TCL (think pascal) pros and cons?
Date: 6 Feb 92 22:53:26 GMT
Organization: MacDTS Mongols

In article <881571s.697225248@aucs>, [e-mail] (Arnold Spence) writes:

> Can anyone BRIEFLY make some points about the advantages or disadvantages of
> using Think Pascal's TCL 1.1 instead of MacApp 2.0. Is one easier to use than
> the other or does one have certain advantages where portability may be a concern

I think they compensate each other quite well. MacApp has nice features for
huge scale applications concerning the view handling and MacApp 3.0 features
(Adorners, Behaviors, DrawingEnvironment, Dependency mechanism and so on),
while TCL could be compiled and used with most small scale Macintosh machines.

As for portability, MacApp is designed and engineered for portability, and I'm
sure TCL is also portable. It's more of a question of

a) large scale development where the features of MacApp pays off
b) size of system where the development work is done, here TCL certainly is
   the viable alternative

Kent Sandvik
- --
private opinions - hey, any program written for the Mac is a good thing, despite
the framework/tools used.



- -------------------------

Organization: Queen's University at Kingston
Date: Monday, 10 Feb 1992 23:58:58 EST
From: <[e-mail]>
Subject:  MacApp vs. TCL (think pascal) pros and cons?

1)  I think that TCL is easier to learn (it's smaller).  However, I'd already
    dug into MacApp (before the book by Larry Rosenstein, David Wilson, and
    Shafer).

2)  MacApp is much more comprehensive.

3)  Apple has changed from doing MacApp in Object Pascal to C++ without a lot
    of consultation (a sort of "Presto!  Here it is!  Waddaya think?").  That
    sort of change worries me about the stability of the product (now that it
    is that basis for many programs, unlike the days when it was half product
    half research).  If I were Symantec/Think ("if I were an entire company",
    I know) I would be reluctant to continue support for MacApp.

4)  MacApp compile-cycles can be a lot longer, particularly if you are using
    MPW.  I imagine that Jasik's incremental build system (I forget the name
    right now) would help.  **Note that I haven't worked with MacApp/MPW for
    over a year now.

5)  There is probably a larger community of people using TCL (the C and Pascal
    versions appear to be identical, particularly if you look at things like
    the use of brackets in the Pascal version).  However, given the light
    traffic on the net about it, I could well be making a bad assumption here.

  Whichever you choose, consider using AppMaker (Bowers Development) as a
learning tool.  You can create programs that have the appearance, even the
basic functions, that you want and then trace through them seeing how your
chosen object-library works.  It's inexpensive, it works, the code is reason-
able, and I've found the company very responsive.

.../dave    Dave Charlesworth



- -------------------------

From: [e-mail] (Chuck McMath)
Subject:  MacApp vs. TCL (think pascal) pros and cons?
Date: 11 Feb 92 13:24:15 GMT
Organization: MSD

I just had a few comments about what Dave Charlesworth had to say regarding TCL & MacApp:

In article <[e-mail]>, [e-mail] writes:
>
> 1)  I think that TCL is easier to learn (it's smaller).  However, I'd already
>     dug into MacApp (before the book by Larry Rosenstein, David Wilson, and
>     Shafer).

    TCL is smaller, but that doesn't make it easier to learn.  I believe one's as easy to
learn as the other, mainly because neither has good tutorial/documentation.  However, you will
find MUCH more written about MacApp (Addison Wesley books, for example) than you will about
TCL. And the developer CD-ROMS contain scads of stuff about MacApp.  Unfortunately, most of
what's written is about MacApp 2.0, not 3.0.

>
> 2)  MacApp is much more comprehensive.

    Agreed.
>
> 3)  Apple has changed from doing MacApp in Object Pascal to C++ without a lot
>     of consultation (a sort of "Presto!  Here it is!  Waddaya think?").  That
>     sort of change worries me about the stability of the product (now that it
>     is that basis for many programs, unlike the days when it was half product
>     half research).  If I were Symantec/Think ("if I were an entire company",
>     I know) I would be reluctant to continue support for MacApp.
>

   Well, Apple made plans, and announced their intentions on AppleLink BEFORE the rewrite was
out (but seemingly after the decision was final).  The resulting flames within the MacApp
community burned hot and long - there was a lot of discussion and arguments and flaming for
approximately 3-4 weeks.  GE (who runs AppleLink) ran a big profit in that period :).

   The rewriting of MacApp probably didn't affect the stability of the product as much as
the introduction of stuff such as support for the Balloon Manager, Publish/Subscribe, Apple
Events, etc, etc.  Each 'major' revision of MacApp (1.0 -> 2.0, and 2.0 -> 3.0) has involved
a BIG rewrite job, with MAJOR structural code changes to the class hierarchies.  Does this
introduce bugs?  Naturally.  The programmers at Apple are good, but they're not gods (except
for Keith Rollin, probably!).  Note that if you think MacApp 3.0 is not stable enough, you can
keep using 2.0 with no penalty.  In fact, many developers that are in the late stages of products
using 2.0 will not convert to 3.0 because it isn't worth it.  However, for new projects, 3.0
is the only way to go.

   Should Symantec continue to support MacApp?  Well, if they came out with a C compiler that
handles it, I wouldn't be surprised if 60-70% of the people using MacApp and C++ switched to
it.  Will they support MacApp?  That's a business decision.  Symantec will ALWAYS be behind
Apple in its MacApp support, simply because Apple creates the code first.  That doesn't mean
that Symantec is out in the cold.  If I were Symantec, I would bust my butt to get a C compiler
out.  It would be a winner.

> 4)  MacApp compile-cycles can be a lot longer, particularly if you are using
>     MPW.  I imagine that Jasik's incremental build system (I forget the name
>     right now) would help.  **Note that I haven't worked with MacApp/MPW for
>     over a year now.
>

   Compile cycles under MPW are very slow unless you have an fx or better.  Did I say very slow?
No, I mean really really slow.  On a IIx it's like watching a glacier melt.  You need 8 MB of
RAM at a minimum, since the CFront tool is a hog.  There is discussion about the development
cycle and its long duration.  At the MacApp conference this month in Orlando there's going
to be some session (I believe - maybe just an informal one) on improving your turnaround times.
Will it get better?  Yes.  Apple has stated in their 'Apple Direct' magazine sent to developers
that one of the things they are working on in 1992 is incremental compiling.  Will it be
as good as the Think compilers?  Probably not.  Will it make more people happy?  Probably.

> 5)  There is probably a larger community of people using TCL (the C and Pascal
>     versions appear to be identical, particularly if you look at things like
>     the use of brackets in the Pascal version).  However, given the light
>     traffic on the net about it, I could well be making a bad assumption here.
>

    I am on MacApp.Tech$ on AppleLink and on the ThinkC mailing list.  IMHO, there is more
activity on MacApp.Tech$.  However, I bet there are a lot of people at universities and at
home who are playing with (no insult intended) TCL.  I have yet to hear of any published
product created using TCL (doesn't mean one doesn't exist, I just haven't heard of one.  Note
that when MacApp came out, you didn't see any products made using MacApp intil at LEAST a
year after the release).

>   Whichever you choose, consider using AppMaker (Bowers Development) as a
> learning tool.  You can create programs that have the appearance, even the
> basic functions, that you want and then trace through them seeing how your
> chosen object-library works.  It's inexpensive, it works, the code is reason-
> able, and I've found the company very responsive.
>

   I'm not familiar with AppMaker (it's on order).  There is a tool for MacApp that has been
warmly described also: IcePick.  It's available from the MacApp Developers Association, and
it allows you to create your views and simulate them (better than ViewEdit).  No experience with
that either outside of reading glowing reviews.

> .../dave    Dave Charlesworth
>

   The conclusion:  use TCL.  use MacApp.  use whatever you want.  use whatever you have the
bucks to buy.  I use MacApp and I love it.  It's not perfect, but the folks working on it seem
to have the desire to make it better and better, and I can't ask for more.

                       --chuck mcmath-
                    [e-mail]
  MSD, Inc. * National Library of Medicine * National Institutes of Health
                       Bethesda, MD 20894



- -------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject:  MacApp vs. TCL (think pascal) pros and cons?
Organization: Kalamazoo College
Date: Tue, 11 Feb 1992 15:19:03 GMT

In article <[e-mail]> [e-mail] (Chuck McMath) writes:
>I just had a few comments ... regarding TCL & MacApp:
> [70 lines deleted]
>I have yet to hear of any published
>product created using TCL (doesn't mean one doesn't exist,
>I just haven't heard of one. )

Mine was.  Released last December.  Now you've heard of one.
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.



- -------------------------

From: [e-mail] (Carl W. Haynes III)
Subject:  MacApp vs. TCL (think pascal) pros and cons?
Date: 11 Feb 92 15:58:17 GMT
Organization: Purdue University Computing Center

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:
>>I have yet to hear of any published
>>product created using TCL (doesn't mean one doesn't exist,
>>I just haven't heard of one. )
>
>Mine was.  Released last December.  Now you've heard of one.

Also, Lotus 123/Mac was reportedly written with the TCL

carl
[e-mail]
AOL:CWH3



- -------------------------

Organization: Queen's University at Kingston
Date: Wednesday, 12 Feb 1992 23:52:13 EST
From: <[e-mail]>
Subject:  MacApp vs. TCL (think pascal) pros and cons?

  This is a quick response to Chuck McMath's useful followup to my note.

> TCL is smaller, but that doesn't make it easier to learn.

Smaller was, perhaps, a poor choice of words on my part.  By "smaller" I meant
"simpler".  You only had to learn three concepts to use TCL 1.0.  MacApp had
nifty things like command objects, that while powerful and useful, muddied the
waters for me while I was trying to develop a basic working knowledge.  Now
TCL 1.1 has added a few things, but it is still a simpler framework I think.
The sword cuts both ways of course, but it's something for someone to consider
when choosing a framework.  If you're writing company-specific tools for
internal use by a relatively small number of people (i.e. your constraints are
well understood and your support channel is good), as I am, then I think that
TCL + AppMaker is a winner for getting something out quickly.

> stability

Another poorly chosen word on my part.  I didn't mean that the code was
unstable, I meant that if you were basing your work on MacApp in Object Pascal,
all of a sudden they were talking a complete shift to C++.  Regardless of the
merits of the two languages, as a business issue it meant a big migration to
turn your application into a System-7 Savvy app.  You alluded to this with
your comment:

> Each 'major' revision of MacApp (1.0 -> 2.0, and 2.0 -> 3.0)
> has involved a BIG rewrite job, with MAJOR structural code
> changes to the class hierarchies.

Both of these revisions have indeed required major rewrites for MacApp custom-
ers as well.  This will be true for major revisions to TCL should they appear.
It points to a larger problem with advancing a framework without orphaning your
customers.  My feeling at the time, though, was that the implications for
business users of MacApp weren't given as much weight as they should have been.
(That is surely debatable though.)  That part is history now, but it should be
a factor for someone developing something that will be long-lived and broadly
distributed.

> Should Symantec continue to support MacApp?

I was thinking of the Pascal group in particular.  They invested what must have
been a monumental amount of effort in changing Think Pascal to support MacApp.
Shortly after that version was released, blam, MacApp wasn't Pascal-based any
more.  These guys weren't working in the dark (they had to be in constant touch
with Apple to keep up with some of the MPW Pascal dependencies being introduced
into MacApp anyway).  When they heard the announcement of the change, their
hearts must have just dropped.  They'd made a major financial commitment to
MacApp and it appeared that it was given no significant weight.

> I have yet to hear of any published product created using TCL

A lot of programming is done for applications that are never published in the
traditional sense.  I think that TCL is a good candidate for many of these.

> The conclusion:  use TCL.  use MacApp.  use whatever you want.
> use whatever you have the bucks to buy.

You're right.  They are both good products.  They are both useful.  I hope
this discussion makes it easier for someone to choose, and encourages people
to start using them.  I believe that using either one will make it easier to
move to the other should you find that the first one doesn't suit your needs.

  Cheers,

.../dave   Dave Charlesworth



- -------------------------

From: [e-mail] (Jon W{tte)
Subject:  MacApp vs. TCL (think pascal) pros and cons?
Date: 13 Feb 92 18:41:44 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.CA> [e-mail] writes:

   > stability

   unstable, I meant that if you were basing your work on MacApp in Object Pascal,
   all of a sudden they were talking a complete shift to C++.  Regardless of the

This is not true. MacApp is completely written in C++, yes, but you don't
have to use C++, you can use Object Pascal, since the MacApp writers have
stayed clear of constructs not supported by Object Pascal. Much to the
chagrin of us C++ developers, of course ;-)

--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



- -------------------------

From: [e-mail]
Subject:  MacApp vs. TCL (think pascal) pros and cons?
Date: 14 Feb 92 17:12:00 GMT
Organization: Queen's University at Kingston

> This is not true.

I think that's a little strong.  My point in this discussion is that if you
were developing in Object Pascal with MacApp you suddenly had a series of
issues to deal with about your tools instead of your "real problem"
(whatever that happened to be).  For example, a working knowledge of the
MacApp source code is still required.  If you were using Think Pascal you
were looking at learning time for people to switch to MPW.  Those are just
a couple of examples.  (Not to mention the case if you were a language
developer who had to recoup an investment in making your compiler MacApp-
compatible; a developer that Apple would want to keep on its side.) It
meant a slowdown when you already had to deal with the new class structure,
and I don't feel that it was necessary (particularly if they're not using
the features of C++).

In summary, I wasn't saying that it wasn't technically possible to convert,
just that it introduced more overhead, and it appears that at the time the
announcement was made, it hadn't been taken into consideration.  (I believe
that _after_ the announcement, this and other issues were well aired by
people such as Kurt Schmucker. However, it seemed to be a 'fait accompli'
by that point.)  I think that the fact that a significant change like this
hadn't been fully considered is a factor that people should consider in
choosing how they will develop their applications.  (I'm certainly not out
to condemn MacApp or the people that have brought it this far.  I know that
people like Harvey Alcabes, Steve Burbeck, and Carl Nelson had to put in
all kinds of effort to keep a great idea alive and moving forward.  I
think, though, that enthusiasm for the possibilities drove this decision,
without a review of the different climates that some MacApp users live in.
This was a major change, and I think more time and discussion would have
helped.)

Best wishes.

.../dave    Dave Charlesworth



---------------------------

From: [e-mail] (Gil Porat)
Subject: Accessing PC files from a Mac
Date: 12 Feb 92 17:25:00 GMT
Organization: SRI International, Menlo Park, CA

I'd appreciate any pointers with the following question.

I need to write a Mac application that accesses a data file on a PC (DOS)
via a network.

Is this possible, and if so how?

What pieces of hardware and software are needed for such a network?
Are there toolkits that would facilitate accessing the PC file from the Mac?

Any help would be appreciated.

-Gil Porat
[e-mail]



- -------------------------

From: [e-mail] (Matt Mora)
Subject:  Accessing PC files from a Mac
Date: 14 Feb 92 01:05:46 GMT
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] (Gil Porat) writes:
>I'd appreciate any pointers with the following question.
>
>I need to write a Mac application that accesses a data file on a PC (DOS)
>via a network.
>
>Is this possible, and if so how?

You might want to install an appletalk card on the pc so at least the
two machines will have a common denominator.

>What pieces of hardware and software are needed for such a network?
>Are there toolkits that would facilitate accessing the PC file from the Mac?

After you have the appletalk network then you might be able to try
sending files via ADSP. (apple data stream protocol).
Michael Pierce has a book on programming using appletalk which would
probably be a big help.

Matt

--
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________



---------------------------

From: [e-mail] (Claude Lapointe)
Subject: HELP!! mistakenly trashed folder
Date: 12 Feb 92 18:56:27 GMT
Organization: Ballistic Research Lab (BRL), APG, MD.

I have inadvertantly trashed a folder containing about 8 files,
2 of which I would like to recover because their last backup was
Jan 9.  The files are data files for Dollars & $ense version 4.1c.
One is about 865K, the other about 810K. The disk partition on
which the folder existed has not been written to since the
trashing. The folder was in a silverlining version 5.23/08
partition on a Cirrus 40-Q disk, and had been moved to the
desktop immediately before being trashed.

getinfo:   Norton Utilities 1.1.2

macenvy:   memory:        4096K
           processor:     motorola 68000
           rom:           128K rev.2 (Lonely Heifer)
           system:        6.0.7
           finder:        6.1.7
           multifinder:   not active
           SysEnvirons:   version 2 available

I had just gotten my copy of Norton Utilities so FileSaver was not
installed.

Quick unerase found 13 files which, based on their names, I
know to be irrelevant.

Unerase by file type, Dollars & $ense 4.0 (note my files are 4.1c),
no advanced options found no files. Selecting exhaustive search
found no files. Selecting unknown file fragments found 36 files.
Only one was of approximately the right size. With its type and
creator changed to EAGD, EAGP respectively, it produced error 23,
incompatible file structure when I attempted to open it under
Dollars & $ense 4.1c.

Unerase by text string found 66 files, each of size 5K. The string
was "college", unique to the 2 files desired.

In addition to using Norton Utilities, I have looked at the disk
partition with CE Software's MacTools v6.2 ViewEdit, but could
make no use of the information displayed, although there were
many recognizable string fragments.

I have access to ResEdit, although I have never used it.

Currently, I am not using desktopmgr (unless it is built into
system 6.0.7), but I do still have files

             desktop DB  last modified 1/26
             desktop DF  last modified 1/4

on which dates I was running system 6.0.4 with desktopmgr.

Thanks in advance



- -------------------------

From: [e-mail] (Marvin Carlberg)
Subject:  HELP!! mistakenly trashed folder
Date: 15 Feb 92 07:15:35 GMT
Organization: Symantec / Peter Norton

As you have discovered, the file format for Dollars and Sense 4.1c is
slightly different from version 4.0 which Norton Utilities can recover.
We can create a new UnErase Signature for the 4.1C files with ResEdit,
but it is probably easier to do so over the phone than email, so if you
can, call Symantec technical support on Tuesday (closed Monday) at
310-449-4990.  We can try to do it thru email too if you'd rather.

-Marvin Carlberg
 Symantec / Peter Norton Group
 [e-mail]



---------------------------

End of C.S.M.P. Digest
**********************